\documentclass[10pt]{article}
\usepackage[letterpaper,hmargin=1in,vmargin=1.25in]{geometry} % page/margin sizes
\usepackage{graphicx}                   % graphics (for figures)
\usepackage{epstopdf}			% Convert .eps to .pdf
\usepackage{amsmath}                    % special AMS math symbols
\usepackage{amssymb}                    % special AMS math symbols
\usepackage{color}                      % colored text and backgrounds
\usepackage{float}
\setlength{\parskip}{3pt plus 1.5pt minus 1.5pt} % extra space between paragraphs
\newcommand\NoIndent[1]{%
  \par\vbox{\parbox[t]{\linewidth}{#1}}%
}
\begin{document}

\begin{center}
\textbf{Assignment 5: Analyzing Network Traces \\Due Tue, Nov 26, 2013\\Luke Valenta}
\end{center}
\begin{description}
%-----------------------------------------------------------------------
\item[{\bf Introduction:}] In this assignment, we analyze various network traces and
use our knowledge of TCP to determine the underlying behaviour of the network and
details of the connection. 
%-----------------------------------------------------------------------
\item[{\bf Receiver Traces }] The following receiver traces were analyzed:

%-----------------------------------------------------------------------
\begin{table}[h]
%
\parbox{.45\linewidth}{
\centering
\begin{tabular}{ l l}
\hline
Trace & airplane\\
\hline
Sender IP:Port & 128.8.126.92:80 \\
Receiver IP:Port & 172.19.131.96:50408\\
Pkts Rcvd & 36432\\
Acks Sent & 22976\\
TX Rate (B/s) & 31528\\
Throughput (B/s) & 31308\\
Total Time (s) & 1674 \\
\hline
\end{tabular}
}
%
\hfill
\parbox{.45\linewidth}{
\centering
\begin{tabular}{ ll}
\hline
Trace & comcast\\
\hline
Sender IP:Port & 128.8.126.92:80 \\
Receiver IP:Port & 192.168.5.162:55868\\
Pkts Rcvd & 37266\\
Acks Sent & 19437\\
TX Rate (B/s) & 1684857\\
Throughput (B/s) & 1636932 \\
Total Time (s) & 32 \\
\hline
\end{tabular}
}
\end{table}
%-----------------------------------------------------------------------
\begin{table}[h]
\parbox{.45\linewidth}{
\centering
\begin{tabular}{ l l}
\hline
Trace & spr\_by\_window\\
\hline
Sender IP:Port & 128.8.126.92:80 \\
Receiver IP:Port & 184.242.145.152:49154\\
Pkts Rcvd & 38425\\
Acks Sent & 20519\\
TX Rate (B/s) & 63772\\
Throughput (B/s) & 60084\\
Total Time (s) & 872 \\
\hline
\end{tabular}
}
%
\hfill
\parbox{.45\linewidth}{
\centering
\begin{tabular}{ ll}
\hline
Trace & spr\_desk\\
\hline
Sender IP:Port & 128.8.126.92:80 \\
Receiver IP:Port & 108.111.143.111:57815\\
Pkts Rcvd & 38385\\
Acks Sent & 22511\\
TX Rate (B/s) & 49563\\
Throughput (B/s) & 46699\\
Total Time (s) & 1121 \\
\hline
\end{tabular}
}
\end{table}
%-----------------------------------------------------------------------
\begin{table}[h]
\parbox{.45\linewidth}{
\centering
\begin{tabular}{ l l }
\hline
Trace & vzw\_desk\\
\hline
Sender IP:Port & 128.8.126.92:80 \\
Receiver IP:Port & 10.175.200.34:57793\\
Pkts Rcvd & 36209\\
Acks Sent & 19507\\
TX Rate (B/s) & 2284830\\
Throughput (B/s) & 2276879\\
Total Time (s) & 23 \\
\hline
\end{tabular}
}
\end{table}
%-----------------------------------------------------------------------
{\bf Analysis}
We can analyze the performance of the trace groups using the metrics given in the above tables. First, we see that the ratio of number of packets received vs. number of acks sent remains fairly consistent among all traces. This is to be expected since the size of the file being downloaded in each trace was consistent (approximately 50MB). However, the throughput for each trace varies quite a bit. The throughput was calculated by the difference in sequence numbers at the start and at the end of the transaction, divided by the time taken for the file to be downloaded. Among all five traces, the highest two throughputs by far are seen in the 'vzw\_dest' and 'comcast' traces, which indicates that these hosts had a much better connection to the server than hosts in the other traces. The remaining three traces all have fairly low throughputs. It is unsurprising that the airplane throughput is the lowest. Also, it is interesting to note that the throughput for Sprint's 3G network is improved by quite a bit by placing the device by the window.\\\\\\\\\\
%

For each of the traces, we plot the sequence number over time, which allows us to analyze when the connection experienced losses and what happened when those losses occurred.

\includegraphics[width = 0.33\linewidth]{figs/airplane_large_out_recv_seq_num}
\includegraphics[width = 0.33\linewidth]{figs/comcast_large_out_recv_seq_num}
\includegraphics[width = 0.33\linewidth]{figs/spr_by_window_large_out_recv_seq_num}

\includegraphics[width = 0.33\linewidth]{figs/spr_desk_large_out_recv_seq_num}
\includegraphics[width = 0.33\linewidth]{figs/vzw_desk_large_out_recv_seq_num}

The most interesting of these plots is the one from the airplane trace. The sequence number plot for this connection shows a significant number of jumps all throughout. This shows that the satellite connection experienced a large number of losses.

For the most part, the other traces show smooth connections with monotonically increasing sequence numbers. Hoever, there are some execptions. For example, the comcast trace is smooth up until it hits around the 30 second mark, at which point the sequence numbers jump down a bit. The most likely explanation for this is that the connection lost a lot of packets at once and had to retransmit all of them.

Next, we plot the estimated congestion window size of the receiver for the connection. These plots actually show the amount of un-acked data in the network at any given time, and is just a rough estimate of the congestion window size. We see a correlation between the congestion window size and the times at which there is a loss of packets (as seen in the sequence number plots). For example, at the 30 second mark in the plots based on the comcast trace, we see a blip in the sequence number plot that corresponds to a very large congestion window in the congestion window plot.

\includegraphics[width = 0.3\linewidth]{figs/airplane_large_out_full_cwnd}
\includegraphics[width = 0.3\linewidth]{figs/comcast_large_out_full_cwnd}
\includegraphics[width = 0.3\linewidth]{figs/spr_by_window_large_out_full_cwnd}

\includegraphics[width = 0.3\linewidth]{figs/spr_desk_large_out_full_cwnd}
\includegraphics[width = 0.3\linewidth]{figs/vzw_desk_large_out_full_cwnd}
 \\\\
Some further plots for the receiver traces follow:

\includegraphics[width = 0.3\linewidth]{figs/airplane_large_out_send_win}
\includegraphics[width = 0.3\linewidth]{figs/comcast_large_out_send_win}
\includegraphics[width = 0.3\linewidth]{figs/spr_by_window_large_out_send_win}

\includegraphics[width = 0.3\linewidth]{figs/spr_desk_large_out_send_win}
\includegraphics[width = 0.3\linewidth]{figs/vzw_desk_large_out_send_win}

%
%-----------------------------------------------------------------------
\item[{\bf Sender Traces }]
For the sender trace, I analyzed the connection between the server and the host\\ "host ec2-54-242-80-150.compute-1.amazonaws.com"

The round trip time plot was generated by keeping track of when packets were sent, and then adding a data point with the difference in timestamps when an acknowledgement for that packet came back. For this connection, the RTT remained fairly consistent except for a few jumps that are likely due to disruptions and packet losses.

\begin{centering}
\includegraphics[width = 0.3\linewidth]{figs/rtt_trace_full_rtt}
\includegraphics[width = 0.3\linewidth]{figs/rtt_trace_full_cwnd}
\includegraphics[width = 0.3\linewidth]{figs/rtt_trace_tx_rate}
\end{centering}

The congestion window plot also verifies that the peaks in the RTT plot are due to packet losses in the network. For instance, the peaks in the RTT plot at the 15, 30, and 35 second marks correspond to peaks in the congestion window graph, meaning that there is a lot of un-acked data in the network. The size of the congestion window determines how much data can be sent across the network at a time. Thus, the policy regulating the size of the congestion window will directly affect the performance of the transaction. The graph of the transaction rate illustrates this. Most notably, we see a sharp decrease in congestion window size at the 15 second mark, which corresponds to a sharp decrease in the transmission rate.
\vspace{110pt}

Next, we show graphs of the unused buffer space at the receiver and the sequence number plot for this transaction. Both of these graphs are consistent with the above graphs in showing packet losses around the 15 and 30 second marks. 

\includegraphics[width = 0.3\linewidth]{figs/rtt_trace_full_unused_buffer}
\includegraphics[width = 0.3\linewidth]{figs/rtt_trace_recv_seq_num}

Finally, we look at the number of duplicated packets and sequence numbers for the sender trace. These numbers are also a good indicator of the number of lost packets in the network.
 
\centering
\begin{tabular}{ l l }
\hline
Total Acks Rcvd & 7924 \\ 
Duplicate Acks & 674\\
Total Pckts Sent & 1348\\
Duplicate Pckts & 1\\
\hline
\end{tabular}

\vspace{300pt}

%
\begin{thebibliography}{9}
\bibitem{carsons}
  Tim Carsons,
  \emph{Programming with pcap}. http://www.tcpdump.org/pcap.htm
\end{thebibliography}
%
\end{description}
\end{document}
